I can make the v2 equivalent changes for you if you want to avoid the hassle of learning to use Gerrit. Would you like me to do that?

Thanks for the offer, @dsnet. I already made the changes actually, but got stuck because the go.mod in the testdata directory specified an older release of grpc-go and I couldn't figure out how to make go get fetch an unreleased HEAD version containing the new interfaces. When I specify the hash for the commit, it says:

$ go get google.golang.org/grpc@7afcfdd66b1241ed5a29e865d838ce19c57fc2d6
go: finding google.golang.org/grpc 7afcfdd66b1241ed5a29e865d838ce19c57fc2d6
go get: inconsistent versions:
	google.golang.org/grpc@v1.2.1-0.20200124224931-7afcfdd66b12 from google.golang.org/grpc@7afcfdd66b1241ed5a29e865d838ce19c57fc2d6 requires google.golang.org/grpc@v1.23.0 (not google.golang.org/grpc@v1.2.1-0.20200124224931-7afcfdd66b12 from google.golang.org/grpc@7afcfdd66b1241ed5a29e865d838ce19c57fc2d6)

I don't understand where the "v1.2.1" part comes from, since nothing seems to reference grpc@v1.2.1 that I can see. There may be something wrong with our master branch - it was used to release v1.0.x and v1.2.0 directly (these tags are in master), whereas now we release on branches, so maybe now go mod thinks master contains a "working" v1.2.1 release. Do you have any ideas for how to work around this? Should we tag master with 2.0.0-alpha or something to trick go mod into treating master as always being at a later version than any release branch? I don't really want to delete the tags since there were official releases at those commits.

Anyway, our next release is tomorrow so I can wait until then for the protov2 changes, unless you know how to make go get happy. Thanks!

I updated go.mod to replace grpc with a specific version (vs. specify it directly as a version dependency), which worked around the problem:

CL: https://go-review.googlesource.com/c/protobuf/+/216399

I don't fully understand why that works, but it does. The version number still seems like a problem with our master branch that I'd like to fix, but this is probably fine for now.

EDIT: s/require/replace

Do you have any ideas for how to work around this?

I'm now thinking we should tag our master branch with v1.<n+1>.0-pre immediately after cutting release branch 1.n - what do you think?

I tagged our commit that set "v1.27.0-dev" in our user agent (right after we cut the v1.26.x branch) with "v1.27.0-pre", and that seems to have done the trick. Unless we hear otherwise, we will do this upon every new release. I also fixed all the tests, which required similar methodology as in the proto-v2 branch w.r.t. a go.mod file in the testdata/grpc directory so that the proper version of grpc (containing these symbols) would be used. PTAL.

I'm curious, do you have the ability to squash and merge, or should I do that for you?

I can't merge at all, because I am not in the golang org, so you will have to do it. Thanks for the review!